Version 3.0 User's Guide
Commands: Cookies	Previous | Next Contents

Cookies, like other kinds of variables, are made up of two parts: a name and a value. They are transferred in the HTTP header of both user requests and server responses, and are stored by the browser on the user's computer.

When the user asks for a page, the server is allowed to send a cookie in the header (it won't be seen in the HTML page) along with the response page it would normally send. The browser is expected to store the cookie so that when it makes subsequent requests of the server it can send the cookie name and value.

NetCloak gives you the ability to create cookies, and it even makes them easy. Cookies have lots of uses, and are actually a lot like user variables. In some cases, user variables may be better because they can be tracked even when a browser doesn't support them and the data doesn't need to be constantly resent by the browser. On the other hand, cookies have the capability of sharing information among multiple servers, or between different add-on tools on the same server. Cookies are also more reliable when users may be coming through proxy servers or have dynamic IP addresses, such as America Online users.

Even if you prefer to use user variables, cookies can be used to help NetCloak track the variables. For users dialing in using shared modem pools or proxy servers, cookies give NetCloak a reliable way to track the user variable data.

<SET_COOKIE cookieName = value expirationDate domain path>

NetCloak supports a default cookie, named "NetCloakID". When this cookie is found, it will use the cookie's value as a key to the user variable data, instead of the user's IP address. To create a randomized default cookie, use the command:

    <SET_COOKIE>

For example, the command SET_COOKIE on your server's home page will generate a string and send it as a cookie named "NetCloakID". If accepted by the browser, all subsequent user variable operations (using either "SET_VARIABLE" or forms submitted by the user) will store the variable data based on this randomized key. If the browser refuses the cookie (either it doesn't support cookies or the user chooses not to accept it), then NetCloak will store user variables using the user's IP address as the key. If you are using User variables on your site, it is recommended that you include a SET_COOKIE command on your home page to improve tracking of users.

Be sure that if you're tracking user variables with the default cookie, you don't overwrite the cookie's value after it is created, or the "link" between the variables and the browser will be broken. You can do this by always checking that the cookie exists using a HIDE_COOKIE command before a SET_COOKIE command, like this:

    <HIDE_COOKIE NetCloakID EXISTS>    <SET_COOKIE>    <SHOW>

In addition to the default cookie, you can also specify up to eight additional cookies per user, named whatever you like. A cookie name may only include alphabetic characters, no spaces, and is case-sensitive. The value is optional; if you specify a value, then that value will be given to the cookie, and if you don't NetCloak will generate a random value for you.

For example, to create a cookie called "BeenThere" with a value of "DoneThat", use the command:

    <SET_COOKIE BeenThere = "DoneThat">

The optional "expirationDate" parameter allows you to specify the expiration date for the cookie. The user's Web browser will store the cookie between sessions and return it on subsequent visits to the page until the expiration date is reached. This allows you to track users between visits to your site. If no expiration date is specified, the cookie will expire when the user quits the browser.

The expiration date is specified either as date@time, in the same format as HIDE_DATE and other commands which accept date parameters, or as an offset to the current date and time. A negative offset can be used to delete a cookie from the browser's "cookie jar" before its expiration date.

For example:

    <SET_COOKIE myCookie "" "1/1/2000@17:00">

Sets cookie "myCookie" to a random value which expires on January 1, 2000 at 5 pm.

    <SET_COOKIE myCookie = 701253 +1.5>

Sets cookie "myCookie" to "701253" which expires in 90 minutes.

    <SET_COOKIE myCookie "" -1>

Deletes cookie "myCookie" from the browser's "cookie jar".

The domain and path parameters allow you to specify which servers and which specific URLs within a server will receive the cookie when requested. If no domain or path parameters are given, then the cookie is sent in every request to the server from which the cookie originated. You can redirect the cookie to another host by specifying that host in the domain parameter, or you can supply a partial domain name so that the cookie is sent to all servers in the given domain. You can use the path parameter to limit the cookie so that it is only sent in requests to a given subfolder of your site. Examples:

    <SET_COOKIE myCookie = "12345" +72 "maxum.com">

Send the cookie in all requests to any server in the "maxum.com" domain for the next 72 hours.

    <SET_COOKIE myCookie = "12345" "" "secure.sales.com">

Only send the cookie to the "secure.sales.com" server until the browser quits.

    <SET_COOKIE myCookie = "12345" +72 "www.maxum.com" "/netcloak/">

Only send the cookie to the "www.maxum.com" server if the URL begins with "/netcloak/", for the next 72 hours.

A special note if you have lots of visitors using America Online browsers: certain versions of AOL browsers only support "persistent" cookies, which means that you must supply an expiration date in the SET_COOKIE command or the cookie will be ignored. So, for best compatibility with AOL users, you should use the following code to track user variables with the "NetCloakID" cookie:

    <HIDE_COOKIE NetCloakID EXISTS>    <SET_COOKIE NetCloakID = "" +24>    <SHOW>

This code will only create the cookie if it does not already exist, giving it a random value and an expiration date 24 hours from the time it is created.

<INSERT_COOKIE cookieName>

This command will place the contents of the specified cookie into the page. For example, if you have set the "BeenThere" cookie noted above you can display it with:

Your Cookie Is: <INSERT_COOKIE BeenThere>

Inserted cookies will appear as you would expect, with the value of the cookie inserted at the point at which the INSERT command is placed.

<HIDE_COOKIE cookieName operator value1 value2...>
<SHOW_COOKIE cookieName operator value1 value2...>

Any HTML text that follows HIDE_COOKIE will be hidden from those users when the specified cookie satisfies the comparison to the specified text.

SHOW_COOKIE operates exactly like HIDE_COOKIE except that is turns the text stream on instead of turning it off.

If the comparison operator is omitted, a "contains" comparison is performed.

For example, assume you have a "planes" page, a "trains" page, and an "automobiles" page on your site. Each of these pages sets the cookie "LastMainPage" to either "planes", "trains", or "autos", accordingly. When the user accesses a form requesting more information, you could use the HTML:

    <HIDE><SHOW_COOKIE LastMainPage IS "planes">    Airplane information can be received...
    <HIDE><SHOW_COOKIE LastMainPage IS "trains">    Train information can be received...
    <HIDE><SHOW_COOKIE LastMainPage IS "autos">    Car information can be received...
    <SHOW>

Here, the cookie "LastMainPage" will always be set to the value defined by the most recently accessed of the three pages.

A simple example of a cookie might be to change the behavior of your server after the user has visited a page or taken some action. For example, you might have a form that asks people which sports car is best... the Porsche Boxter, the Mazda Miata, the BMW Z3, or the Honda DelSol VTEC. You could gather the results using global variables, use local variables to display the relative percentages of each car, and use a cookie to remember that the user has already voted and disallow them from voting again.

Copyright © 1996-1999 Maxum Development Corporation http://www.maxum.com/	Previous | Next Contents